Embedded systems are responsible for the control and functions of many modern road vehicle's systems or subsystems. An embedded system in the automotive context is also known by other names such as ECU (Electronic Control Unit), ECM (Electronic Control Module) and CCM (Central Control Module).
The development of automotive embedded systems mainly evolved in isolation of the general computer industry. Most embedded system developers are domain specific (i.e. their programming language knowledge and skills are confined to a specific field such as automotive) and often narrowed down to specific platforms and processors. They are also usually engineers trained in traditional areas such as automotive, electrical/electronics and telecommunications (as opposed to programmers and software engineers). Like the rest of the auto industry, the growth of vehicle embedded technology is very much organic and gradual relative to the fast and often disruptive growth of the general computer industry. Since automotive embedded system development is very much independent of the general computer industry, automotive embedded system developers usually do not have to keep up with the rapid changing technology of the general computer industry.
The State of Road Vehicle Embedded Systems
Prior to the 1980s, road vehicles consisted of mainly mechanical systems. By 2010, it was estimated that electronic systems account for approximately 40% of a vehicle's cost.
The integration of embedded systems into road vehicles is an uptrend; in order to incorporate more functionalities, vehicle manufacturers have been integrating more and more embedded systems into their products. These embedded systems are commonly driven by a combination of networked microcontrollers, programmable logic controllers (PLCs) as well as real-time operating system (RTOS) based microprocessors.
These embedded systems can be found in various segments of operation such as powertrain, safety, vehicle controls, driver assistance, comfort and convenience as well as infotainment and communications.
The embedded systems used in road vehicles also employ various communications protocols such as Controller Area Network (CAN), FlexRay, Local Interconnect Network (LIN), Vehicle Area Network (VAN), Media Oriented Systems Transport (MOST), Time-Triggered Protocol (TTP), SAE J1850, J1708, J1587 and J1939 to name a few. The level of adoption of these protocols depends on individual vehicle manufacturers.
AUTOSAR (AUTomotive Open System Architecture), a development partnership formed by major vehicle manufactures, suppliers and tool developers have tried to reign in the non-uniformity in the area of automotive embedded systems by coming up with a standard architecture whereby future vehicle applications would be based. However, the criticism was that some influential players within the partnership have managed to lobby for certain elements (e.g. existing standards used by them) to be included as part of the new standard contrary to the interests of other AUTOSAR members. This has created what critics claimed as a “bloated standard”, meaning a standard with “too many standards and definitions”, resulting in more complexity and fragmentation under a new name.
The Results of Integrating More Embedded Systems Into Vehicles
Many vehicle manufacturers today are essentially system integrators. Although certain systems and subsystems are still developed and built in-house, it is not uncommon for vehicle manufacturers to also source entire systems and subsystems from external suppliers in order to reduce development time.
In many cases, these systems and subsystems are also supplied with their own embedded systems, software and sometimes even their own RTOSes. As a result, there are more processors, cabling, embedded software and protocols to integrate and reconcile. The result is an exponential increase in complexity that vehicle manufacturers and suppliers are finding increasingly difficult to manage.
Adding to the problem is the inherent complexity of these embedded systems. Integration and testing are complicated because a lot of these embedded systems operate on the basis of hardware event triggering, and so could produce unexpected interrupts, interference and conflict in resource sharing when interacting with other embedded systems.
Debugging embedded system related problems can be tedious and sometimes impossible within the relatively short period of time allocated for vehicle testing. (In the past, it is not uncommon for vehicle development to take five years. Today, many vehicle manufacturers roll out a new model within two to three years). Hardware interrupts in automotive context can be very hard to trace due to the multiplicity of embedded systems and their often complicated interactions with each other. Moreover, the condition that produced certain trigger events can be extremely difficult or impossible to replicate in laboratory conditions. It does not help too that many suppliers do not permit vehicle manufacturers to access the source code of their software. Without viewing the source code, the task of debugging is made a lot harder.
If software bugs were found after the vehicles have entered into production, then a recall may be the only option. The same goes if any embedded system needs to be updated with additional safety functions post vehicle delivery to customers.
Compatibility issues are also becoming increasingly common as more and more vehicle manufacturers attempt to support connectivity for third party devices (e.g. tablets and smart phones) in their vehicles for infotainment and communication. As discussed earlier, automotive embedded systems have evolved mainly in isolation of the general computer industry. On the other hand, these mobile devices (which are part of the general computer industry) run operating systems and software that are updated in as often as monthly or even more regularly. Consequently many such vehicles are beginning to experience software conflict between its own system and the third party systems when they are put together. In other words, vehicle manufacturers are struggling to keep up with change.
As for suppliers, to satisfy the requirements of vehicle manufacturers is no easy task either. Often times different vehicle manufacturers have different preferred development platform as well as protocol sets of their own. Hence suppliers must ensure that their products are compatible with the platform of all the manufacturers they supply. It is also often necessary for suppliers to be staffed with specialised manpower knowledgeable in different development platforms and processors, for both new and legacy products that they are required to support. These specialists can be difficult to source, and if available, often command high wages, further driving up the cost for suppliers.
Over the years, the job as well as training of service technicians have also become increasingly more complicated and specialised. Due to the myriads and multitudes of embedded systems used in vehicles, many service technicians have to specialise in a group of similarly built vehicles. With certain manufactures, some of these technicians have to even specialise in a single brand. Such specialisation have resulted in technicians being able to service a limited make of vehicles, hence reducing their market opportunity and customer base.
If the current trend (of integrating more embedded systems into vehicles) continues, we can be assured that vehicle manufactures and suppliers will have to wrestle with increasing complexity, cost, greater liability due to potential safety issues and longer time-to-market. Service technicians will have to be contented with narrower customer base or encounter “black boxes” they have neither seen before nor know how to service.
Very soon, end users will experience and increase in system conflicts, especially when using their mobile devices in conjunction with their vehicles (with some being potentially dangerous) as well as higher maintenance cost of their vehicles.